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1 . We, INTERNATIONAL BUSINESS MACHINES CORPORATION, a corporation of New York, 
having a place of business at Armonk, New York 10504, United States of America, are in 
possession of an invention which is described in the accompanying provisional specification under 
the title "IMPROVEMENTS RELATING TO DESIGN OF OBJECTS AND INTERFACES". 
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of the right to make this application. 

4. We declare that to the best of our knowledge and belief the statements made above are correct and 
there is no lawful ground of objection to the grant of a patent to us on this application, and we pray 
that a patent may be granted to us for the said invention. 

6. And we request that all notices, requisitions and communications relating to this application may 
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We, INTERNATIONAL BUSINESS MACHINES CORPORATION, a corporation of New York, 
having a place of business at Armonk, New York 10504, United States of America, do hereby 
declare this invention to be described in the following statement: 
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The invention includes any combination of features mentioned herein. Known equivalents of 
these features are also included. 
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1. Describe your invention, stating the problem solved (if appropriate), and indicating the advantages of 
using the invention. 

Client design involves three major steps. They are: 1) View Design 2) Business Object Design 3) Business Case Flow Design. 
Traditionally, all these steps are mixed into a single process resulting in lots of complexities in terms of development and 
maintenance of the software. This invention proposes a design in which the above 3 steps can be progressed independently, 
as there are well-defined interfaces that bind one step to the other. 



2. How does the invention solve the problem or achieve an advantage .(a description of "the invention", 
including figures inline as appropriate)? 

This invention proposes the development of 3 major entities. They are: 

1. View Implementation 

2. Business Object Implementation 

3. Business-Case Handler Implementation 

The View implementation makes use of a data object interface for the business object implementation while the business-case handler 
makes use of the business object interface for the business object implementation. After agreeing on these 2 interfaces, the 3 steps 
involved in the development could proceed independently 

The view essentially presents the business object and is not concerned with the business logic. However, a view may trigger 
the start of some business logic (for example, pressing the save button etc.). The handler, on the other hand, coordinates a 
sequence of actions that need to be performed on a set of business objects to implement a business case. This way the 
handler makes use of the business object interface of the business object implementation while the view makes use of the 
data object interface of the business object implementation. This gives a clear separation between presentation and 



Isolating UI Desisi from Business Object Design using Java Interface concepts - continued 



business logic on the client The main advantages of this invention are: 1) separation of presentation and business logic, 
which easily translates to a web-based client development approach 2) independent development of the views (by UI 
specialists), business object implementation (developers) and business-case handler (business analyst who knows the 
business case well). Because the views trigger the start of a business case they need to notify the handler that governs the 
business case. This is done via a listener interface. This way the dependency between the view and the handler is totally 
eliminated. 

The invention describes the construction of the client in a step-wise fashion. The various components involved in the design 
are shown below. 
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3. If the same advantage or problem has been identified by others (inside/outside IBM), how have those 
others solved it and does your solution differ and why is it better? 

The trend is to develop the client as an application in a single step. This solution is definitely different from the conventional 
approaches as it clearly divides the work into different domains that can be handled very welt by experts in the domain. Even 
though there is an emphasis on the need to separate content presentation with business logic with the advent of the model, 
view, controller paradigm and with servlets and JSP concepts, none of these approaches define the data object interface and 
the business object interface as a means of separating content presentation from business logic. 



4. If the invention is implemented in a product or prototype, include technical details, purpose, disclosure 
details to others and the date of that implementation. 
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Refer to the Client Architecture Document for Customer Hierarchy 
Client Developer Guide Revision 1 .d( 
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The problem: 

Client design involves three major steps. They are: 1) View Design 2) Business Object Design 3) Business Case 
Flow Design. Traditionally, all these steps are mixed into a single process resulting in lots of complexities in terms 
of development and maintenance of the software. This invention proposes a design in which the above 3 steps can 
be progressed independently, as there are well-defined interfaces that bind one step to the other. 

Client Development Steps: 

This invention proposes the development of 3 major entities. They are: 

1. View Implementation 

2. Business Object Implementation 

3. Business-Case Handler Implementation 

The figure given below, shows these 3 entities interacting with each other to implement a business case. 
The View implementation makes use of a data object interface for the business object implementation while the 
business-case handler makes use of the business object interface for the business object implementation. After 
agreeing on these 2 interfaces, the 3 steps involved in the development could proceed independently. 

Also shown in the figure are the various interfaces, which separate the 3 entities from each other. This 
implementation is different from the concept of JSP, Servlets and Entity Beans due to the following reasons: 

1. JSP, Servlets and Entity Beans apply to web based systems. Though they could be extended to a typical client 
based solution where a JSP could correspond to a GUI View and the Servlet could correspond to the handler and 

the Entity Bean could correspond to the Business Object there is a fundamental difference in the way they function. 
In a web based environment the pages are sent by the server for the client to display while in a client application 
the views are created on the client itself. In web based applications, information from the html pages currently 
displayed are communicated to the servlets with the help of forms. While in this invention, the views communicate 
with the handlers of the business case with the help of objects called view contexts. In short, in this invention, we 
get all the advantages of an object oriented design as all entities are objects while in web based systems they are 
not. 

2. The web based design addresses the need for separating content presentation from business logic. 
This invention also talks about the same aspect though in a different way. This invention lays emphasis 
on the usage of a data access interface and a business logic interface to the same business object 
implementation to clearly separate content presentation from business logic. ^ 

3. This invention also talks about the definition of business case design and implementing this as a 
separate step and isolating it from presentation and business object implementation. 



Overview of Client Architecture 
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The following figure illustrates the interfaces that clearly separate the 3 entities in the design. The 
interfaces are positioned at the comer of a triangle. We can clearly see how the view and the handler 
communicate with the business object. The view accesses the data accessors through the data object 
interface of the business object implementation while the handler makes use of the business object 
methods defined in the business object interface. The handler and the view interact through the view 
and view context interfaces. 



• Interface* 
View 



+refresh(vc : ViewContext) : void 
+hide() : void 
+dispose() : void 



CustomerView 



-CustomerName : TextField 
-CustomerNumber : TextField 
-OKButton : Button 
-CancelButton : Button 



refresh(vc : ViewContext) : void 
+hideO : void 
+dispose() : void 



« Interface* 
CustomerView Listener 



+OKButtonPressed(event : Event) : void 
+CancelButtonPressed(event : Event) : void 



CustomerHandler 



+OKButtonPressed(event : Event) : void 
+CancelButtonPressed(event : Event) : void 



« Interface* 
ViewContext 



Y 



CustomerViewContext 



+getCustomerDO() : CustomerDO 




Also known as 
CustomerBOImpI 



• Interfaces 
CustomerDO 



+setName(name : String) : void 
+setNumber(number : String) : void 
+getName() : String 
getNumberQ : String 



•Interfaces 
CustomerfiO 



+update() : void 
+retrieve() : void 
+delete() : void 
+create(] r. void 




CustomerDataPeer 



-Name : String 
-Number : String 



y +setName(name : String) : void 
+setNumber(number : String) : void 
+getName() : String 
«-getNumber() : String 
Hjpdatef) : void 
+retrieve() : void 
+deleteO : void 
+createQ : void 



The above class diagram illustrates the structure of the various entities for a sample business case 
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— 5. retrieve(C ustomerDataPeer) 



10. Populated 
CustomerDataPeer 



-6. retrieve(CustomerDataPeer) 
1 



9. Populated 
CustomerDataPeer 



The above diagram illustrates the typical interaction diagram for the simple business case of retrieving 
the details of a customer. 
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3.3 Projects and Packages 

All business objects VisualAge Java does not allow a package to be present in two projects on a 
single workbench. Hence, the business objects belonging to an ICMS component must be kept in a 
separate project named with component 

In 5.1, since the Customer Hierarchy andMSPPP configurator were developed in parallel and the 
development standard was evolving, the packages containing common business objects placed in 
each project. The situation must be remedied as explained in the subsequent sections. 

3.3.1 ICMS Customer Care 

This should include: 

• Com.ibm.icms.customercare.businessobject 

• Com.ibm.icms.customercare.businessobjectimpl 

• Com. ibm.icms.customercase. test 



33.2 Product Management 

• Com.ibm.icms.productmanagement.businessobject 

• Com.ibm.icms.productmanagement.businessobjectimpl 

• Com.ibm.i cms. productmanagement. test 

333 ICMS 

• Com. ibm.icms. parameters, bus inessobject 

• Co m. ibm.icms. parameters, bus ines so bjectimpl 

• Com. ibm.icms. businessobject 

• Com. ibm.icms. businessobjectimpl 

• Com.ibm.icms.ui 

• Com.ibm.icms.util 

• Coni. ibm.icms. test 



33.4 IBM Utilities (all IBM packages for utilities) 

33.5 IBM ET 400 (AS400 connection) 

33.6 Customer Hierarchy 

• Com. ibm.icms. customercare. hierarchy, app 

• Com.ibm.icms.customercare.test 

33.7 Usability 

• Com.ibm.icms.productmanagement.msppp.app 

• Com. ibm.icms. productmanagement.msppp. test 
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3.4 Common Reusable Implementations 

3.4.1 Scrolling 

The following example illustrates the coding required to scroll on a customer business object: 
Define CustomerListlmpl as 



public class CustomerListlmpl extends BusinessObjectListlmpl { 
private CustomerHomelmpl ivParentBOImpl; 



Define CustomerListFIlter as 



public class CustomerListFilter extends BaseFilter { 
private String ivCurrency = null; 
private int ivCycle = 0; 
private int ivFrequency = 0; 

} 



Implement a method in CustomerHomeRemote to get the list first time. In this example the 
signature appears as follows: 




Implement a method to retrieve the next set in CustomerHomeRemote. 

• Implement the method re trie ve Next SetQ in CustomerListlmpl. The implementation should 
call the method to retrieve next set in CustomerHomeRemote. 

3.4.2 Parameters 

The classes that are used for this are: 



• ParameterDO (Java interface) 

• ParameterHomeBO (Java interface) 

• ParameterHomelmpl 
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• ParameterlmpI 

• ParameterHomeRemote 

• ParameterListlmpI 

ParameterHomelmpI maintains a hash table of collections of various parameter types. There is a 
method to retireve the list of parameters of a certain type as ParameterListlmpI through BOList 
interface. If the parameter is already retrieved from the server, then the list is simply returned to 
the user. If this is the first time, a particular parameter type is requested, then it uses the 
ParameterHomeRemote to get the list from the server. . 

Each element in the ParameterListlmpI is a ParameterlmpI object which can be accessed through 
ParameterDO interface. 

If there are some parameters that are not standard and has extra attributes, then specific class must 
be defined inheriting from ParameterlmpI. See ParameterNotificationlmpl for an example. 

3.4.3 Exception Handling 

The major classes used are: 

• BusinessErrorlmpI and BusinessError (Interface). This encapsulates each error message 
between client and server that are generated by the application. The error message, code and 
severity are available in this. 

• BusinessException manages list of business errors. This is subclassed from standard 
exception. In general, when a business rule is violated this exception is thrown. In general this 
will be raised in side BORemote classes as this is where the server programs are called. It is 
possible to raise them in BO classes as well, if a business rule is implemented locally. 

• The following classes handle the exceptions: 

• BusinessObjectRemotelmpl. This handles the exceptions to collect information and then 
throws it again 

• BaseHandler. This is the ultimate class that responsible to display the error to the user 
when required. It decides based on the severity if the error is to be popped up or shown in 
the status bar or simply logged. 

3.4.4 Help Integration 

The major classs used is: 

• BaseHandler. It listens for any help event generated by pressing PF1 . This invokes a browser 
with appropriate URL for the help. 

3.5 API Design Considerations 

• Each API should be commitable by itself. 

• Do not allow nested scrolling. 

• Do not get the same state information of a business object from multiple APIs. 
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4 Client Application Development 

-Development of the (UT) User Interface portion of the application is best described by an example. The 
example chosen has been demonstrated in Customer Hierarchy, the scenario involves retrieving a set of 
customers matching a context. To do this, the User invokes the Find Customer function from the Hierarchy 
Builder and enters a set of search criteria, a set of matching customers is displayed. The example focuses 
on development of the find customer function and its invocation from the Hierarchy builder. 



The diagram below shows a high level flow of events to retrieve a list of customers for a search criteria 
entered by the user. 



FindCustomer 
Dialog 



Step4 



FindCustomer 
Listener 



FindCustomer 
Context 



FindCustomer 
Handler 




Stepl: 

The user enters search criteria and presses the find Button. The FindCustomerDialog creates 
a FindCustomerContext object and populates the context object with the search criteria . 

Step2: 

The FindCustomerDialog fires the findCustomer event which encapsulates the context object. 
Step3: 

The FindCustomerListener detects the findCustomer event and forwards it to the FindCustomerHandler 
for processing. The FindCustomerHandler invokes the appropiate API that retrieves the list of customers. 

Step4: 

The FindCustomerHandler refreshes the Window with a list of matching Customers. 

The following sections describes in steps how a developer builds the view the associated control classes to 
implement the Find Customer Function: 
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4.1 Step 1: Coding the Window 

Prerequisite: The developer must be familiar with the Ul Interface style guide for User interfaces. This is 
found in doc XXXXXXXXXXXX. 

The Window can be a Frame or a Dialog. In the Customer Hierarchy application the primary window 
(HierarchyBuilderView) is a resizable frame, all secondary windows are Dialogs. The Find Customer 
window is a dialog. 

The developer should use the Visual Composition Editor (VCE) feature of Visual Age for Java to construct 
windows. Advanced developers may code windows by hand with using the VCE. The advantage of the 
VCE is that you can visually see what you are developing. 

4.1.1 Step 1A: Layout the Window in VCE 

Use the VCE to layout the Window. Make sure that you are familiar with the UI Style Guide to ensure that 
fonts, pushbutton sizes and the correct widget types are used. 

4.1.2 Step IB: Externalise Window Literals 

String literals will be used as labels for the Window title, pushbutton text, static text, etc. These literals 
should be externalized into a ListResourceBundle class to allow translation to other languages. 

Example: ListResourceBundle used in Customer Hierarchy 




To access items from the ListResourceBundle: 

Example retrieves the text from the ListResourceBundle that matches the "cancelBtn" key 







pi 




j'rce Bund 1 e^getSWng("cyicel^n';'J)g^ 

















4.1.3 Step 1C: Create Listener Inteface 

Create a new Listener interface in the View. This will create the necessary classes ( Event Class, Listener 

Class, and EventMulti caster Class) that will allow the Handler to process business events. The New 

Listener interface is create in the VCE by selecting the Features menu->New Listener Interface. 

Add the events that you wish the Listener to handle. In the Find Customer Scenario events that we wish the 

Listener to detect are: 

1. FindCustomer 
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2. GetNextMatches 

3. ShowDetails. 



The VCE creates the necessary events prefixed by "fire". These methods can be customized. An example 
of the fireFindCustomer method generated. 




4.1.4 Step ID: Add Connections to Listener Events 

Add connections to widgets that require a server API to be invoked: 
The connections are indicated by the dotted lines. 




4.1.5 Step IE: Handle local Window Events 

Simple events that do not require invocation of Server APIs should be handled locally within the view. 
An example is the User pressing the Clear pushbutton to clear data entered and retrieved from a previous 
search. 
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These events are handled in the actionPerformed method in the Window, For Example: 




4.1.6 Step IF: Window Initialization 

Perform any window initialization in the initialize method. This may include setting default button states, 
setting default values in lists and combo boxes. 

The initialize method is regenerated each time window is modified in the VCE. To avoid losing user code 
ensure this code is placed begin: 
// user code begin 

some code 

// user code end 

Sample initialize method in FindCustomerDialog: 




Rule: All Frames should be subclassed from BaseFrame. 
Rule: All Dialogs should be subclassed from BaseDialog. 
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Guideline: Use a Layout Manager to ensure that the window can be sized correctly. 

Guideline: Minimize the use of connections within the visual builder. Too many connections clutter the 

builder screen and the code generated is inefficient. 

Guideline: Typically use connections to connect actions that require events to be handled by a Handler. 
Validation: 

Guideline: Syntactical validation should be performed in the view. Examples of syntactical validation 
include: 

1. Field Length 

2. Field Type ie. input field that accepts only numeric characters. 

Guideline: Semantic validation should take place on the server. This encompasses all business rule 
checking. 

Guideline: GUI actions that do not trigger server API's should be handled by the window itself. These 
actions are typically triggered by implementing an action listener for the particular event 



4.2 Step 2: Coding the Context Object 

Context objects are used to pass information between the view and the Handler. The Context object is 
usually encapsulated within the Event object that gets triggered from the View. 

In the Find Customer scenario, a FindCustomerContext object is used to hold the search criteria for the 
search and the result list for the matching customers. 



The following code segment shows a definition of the FindCustomerContext 




Guideline: A Context object should be used to pass information between view and Handler 
Rule: All Context objects should subclass from BaseContext. 



4.3 Step3 ; Coding the Handler 
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The Handler is responsible for processing satisfying business requests that are generated by the View. In 
the Find Customer Example, the business requests that require Handling are: 

1 . Find Customer 

2. Retrieve Next Customers 

3. Open Customer Details. 

Rule: All Handlers subclass from the BaseHandler. 

Rule: The Handler is responsible for invoking server API's. 



Rule: The Handler creates the view and associates any require listeners to the view. 




Rule: Handlers can create other Handlers. 

In our scenario, the Handler for the main window (HierarchyBuilderHandler) creates the 
FindCustomerHandler 
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The standard pattern used to invoke a Server API is demonstrated in the code segment above. Two Runnacie objects 
are created one to hoid the request and the other the response. The invoke method queues the request and response 
objects to be run sequentially on the ICMS ThreadSupport object. Presently, only one request will be satisfied at a time. 
The ThreadSupport object creates a separate worker thread to first run the request runnable object. Once the request 
runnable object returns, it queues the response runnable object on the Java event dispatching thread. This is necessary 
as the updates to Ul should always be done by the event dispatching thread as swing components are not thread safe. 
The event dispatching thread then refreshes the Ul with the results. In future, more than one request cculd be queued 
with the ThreadSupport object. We may assign threads from a pool to do the job or strictly serialise the execution of all 
request runnable objects. This serialisation is needed because of AS/400 toolbox mechanism of creating one AS/400 job 
per connection to the AS/400. If a single AS/400 job is accessed by several threads then problems relating to commitment 
control may occur. Hence, it's always safe to limit the number of worker threads to only one and queue ail background 
processing requests {just like the event dispatcher thread). 

Runnable objects are created to improve responsiveness of the user interface by running each Runnacie or. a separate 
thread. 

Refreshing of the User Interface should take place in the response object. In our scenario the FindCustomerDialog is 
updated via the refreshFindCustomerDialog passing the FindCustomerContext which contains the matching customer list 
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Guideline: BusinessObjectEditabteList, and BusinessObjectList should be used to represent lists of objects that and to 
be displayed in the View 

4.4 Step 4: Exception/Error Handling. 

Error handling occurs in the BaseHandler, all business errors are displayed to the user in a ErrorOialog while warning 
messages are displayed in the application's status line. 

The VCE creates a handleExceptionQ method. This method needs to be deleted as exceptions are handled in the base 
handler. 
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A Client Business Object Design Guidelines 

Lazy State Evaluation for the Business Objects: 

The business object has a corresponding client side representation of its state. This is achieved with the 
help of the value objects which form a part of the business object's server side state. As a given business 
object is made up of a number of data objects it is possible to lazily evaluate the state of the business object 
by invoking the corresponding retrieve methods on the client. Example: For the Package Business Object, 
in order to evaluate the summary information, the "retrieveSummary" method is called. To evaluate the 
Prerequisite list, the "retrievePrerequisiteList" method is called. 

Business Methods in the Business Objects: 

Business Objects have methods that correspond to an AS/400 API call via the AS/400 ToolBox for Java. A 
business method call on the BO is translated into an AS/400 API call via the toolbox. This involves 
conversion of Java data types into RPG data types (done with the help of the Tool box translator classes). 

Summary of business classes and business methods: 
PackageHome 

Void Retrieve(PackageKey key) 

Retrieves all packages starting from the key position 

Void RetrieveAIl() 
Retrieves all the packages 

Package nextPackageO 

Returns the next package from the currently retrieved list. The positions are maintained with the help of a 
context token/cursor inside of the home. 

Package previousPackage() 

Returns the previous package from the currently retrieved list. The positions are maintained with the help 
of a context token/cursor inside of the home 

Boolean hasPreviousPackageO 

Returns true if there is a previous package from the current position of the cursor 
Boolean hasNextPackage0 

Returns true if there is a next package from the current cursor position 
Package intialPackageReference(PackageKey key) 

Returns a reference with key. This method creates a reference or a proxy object locally with the key 
information. The successful creation of the reference object does not guarantee the existence of the 
business object in the database. This business object reference could then be used to populate information 
about the BO by calling appropriate retrieve methods or create new objects by calling the create method. 

Package 

Void RetrieveSummaryO 

Retrieves the summary information for the business object "Package" 

Void RetrieveGenerallnformationQ 

Retrieves the general information about a package BO. 
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B Business Case Handlers 

Non-Functional Requirement 

1 . Design should identify elements of reuse 

2. Design should take care of separating functionality, where necessary, so that it could be extended 
easily by adding code and not modifying existing ones. 

Examples: 

The following examples illustrate the elements of reuse. 

Consider a "Find" View. This view typically displays some entry fields to capture the search criterion and 
displays a result set Now this view could be reused in a number of places. The context in which the view is 
displayed should be independent of the view. This means that the knowledge that an advanced search 
window would appear when a customer search is initiated and a simple search window would appear in 
case of a hierarchy search should not be embedded in the "Find" View itself. If it is embedded in the view 
then it is reusable only to the extent that all such possibilities of the next window that appears from the 
"Find" view is known. The design is not extensible if the knowledge is captured in the view. 

Separating functionality is an important concept in OO designs. We should be able to identify small 
reusable objects. This way we increase reusability. We know that the smaller the object is, the more 
reusable it becomes. However, the potential pitfall here is when do we stop? If we keep making the objects 
more and more granular they become more reusable but less usable. Practically, it may be impossible to use 
them at all. Hence there should be a compromise as to what the size of an object is and what its reusability 
is. We decided to draw the reusable line at the view level than at the view components level. We made sure 
that each view is made up of smaller and reusable components provided by standard Java Swing 
Components and also some third party components (e.g., DatePicker). 

An application could be thought of as being made up of a number of business cases. A business case may ' 
be one of 1 ) Finding a list of customers satisfying a given search criterion, 2) Creating a new hierarchy 3) 
editing an existing hierarchy etc. These are typically called as use cases in OO design. 

Write down the various steps involved in a business case. 
For example: 

1) In order to create a new hierarchy, the user is presented with a dialog window, which captures the 
details needed to create a hierarchy. 

2) When the user presses OK a call is made to the server to create the new hierarchy and the UI on the 
parent window is refreshed to show the new hierarchy. 

These steps are then translated into the screen flow diagram and the object sequencing diagrams. The 
screen flow diagrams shows what screen follows what in the business case. The object sequence diagram 
shows what objects interact to get the job done. In order to separate the functionality, the business case is 
captured as a handler. Once the application identifies the business case, it would create an appropriate 
handler and pass control to it. In fact, the application itself could be thought of as a handler. 

The handler governs the UI flow, i.e., creates views in sequence, creates appropriate business objects and 
invokes business methods in them, handles the errors appropriately and disposes off the window. 

The window is responsible for presenting details of a given business object (its state information) and 
populating the state of a given business object (captures the entry details for a given business object). 
However, it does not understand the operations performed by users from a business perspective. For 
example, pressing the OK button, would indicate to the handler that the details entered for a given business 
object should be committed. However, the view itself doesn't understand the meaning of the OK button 
pressed. However, the view may understand drag and drop events and other events that relate only to the 
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view. If the drag and drop results in a business event then it is passed on to the handler as it may trigger a 
totally new business case. This way we classify events as business events and view events. View events are 
handled by the view. The handler governs the business events. This is important, as a mix of the two would 
result in an inefficient design. The advantages of separating the two are as follows: 

1) Same business events triggered by different views could be targeted to the same handler. For example, 
consider two entirely different windows having a help button or a find button. If we know that pressing 
the help button/the find button would bring up the same business case then the business event could be 
re-targeted to the same business case handler. This is important as we are trying to follow a use-case 
based approach and one use-case can extend a given use case or be part of a larger use-case. Modeling 
a use-case, with handlers, results in very good reuse of the handlers. 
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C Client Design guidelines: 

The view captures the data portion of a business object(s). The business object exports the data object 
interface and the business object interface. The data object interface is used by the view for presentation 
purposes. The data object interface is also called the presentation interface of the business object The 
business object interface captures the business logic. The central idea is to capture all the data object 
interfaces (relating to a given view) into a single object called the View's context object (also known as the 
View Data Model object). The primary reason for the introduction of the context objects relates to the 
threaded client design. Because of the presence of a GUI thread and a corresponding background thread, 
the GUI events are totally detached from the background work. In order to relate a given GUI event to a 
background job and to trace back, a state or some context is necessary. Any view, in this design, could be 
reinstated if the context is known. The context is like a snapshot of a view data. The view can recreate itself 
given the context. The view can register the last user operation in the context The handler registers the 
result of the last operation in the context. The view takes appropriate actions based on the results of the last 
operation. 

In response to a user event, the View constructs a business event by associating its context with the 
business event The view may store specific information (like the operation performed) in the context that 
may not be visible to the handler. The view then fires the event at its listeners. Since the handler is a 
listener, it is notified of the business event that happened in die view. The handler then handles the business 
event by calling appropriate business methods on the business object. The handler executes the business 
methods using the background thread. Once the execution completes, the handler can register the results of 
the operation with the View Context and can refresh the view with this updated context. Thus with the help 
of context objects the view and the handler interact and also synchronize. 

On the other hand, if the business case is an extension of another business case the handler may decide to 
post the request to the handler of the other business case. It has to first convert the event that it received 
into an event that the other handler recognizes. On completing its task, the second handler, posts a reply 
back to the first handler (which is registered as the parent handler of the second handler) passing back the 
updated event (should be called the handler context). The original handler can then refresh the view with 
the new updated context In this design, the calling handler is not aware of the views that the called handler 
might bring up. This is very essential in a good design as they clearly separate handlers too. 
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D Ul Implementation Steps 

From visual builder do the following: 

1) Define accessors for fields that may be accessed from outside the view. 

• Choose methods tab from the visual composition editor 

• Press the methods button to create a new method 

• Type in the method name, choose method parameters and modifiers 

• Define the method body. 

Example: 

Public final void setCode(String str) { 
GettfCode().setText(str); 

} 

public final String getCodeO { 
return gettfCode0.getText(); 

} 

• Repeat the above steps until all relevant accessors are defined. 

2) Define Listener interface for relevant GUI events that cannot be handled by the view internally. 

• Choose Features / Create new listener interfaces and within that create methods to handle each 
event. One listener interface for group of events 

• PackageDetails - interface with methods PakcageDetailsOKed, PackageDetailsCancelled, 
PackageDeta il s Ap plied 

3) Use the visualBuilder to locate the components that will generate the events. For instance choose, OK, 
Cancel, Apply. Then in the Event-to-code interface of the component, simply select the corresponding 
event-fire method to invoke for the corresponding component events (ie. A button, will generate action 
events. The event-fire method should be linked to the action-event). 

4) Define handlers for the view. The handler should also implement the interfaces provided by the view 
inorder to be able to listen to the events generated in the view. The handler can implement all the 
interfaces or there could be separate handlers for each of the interface. 

• Define a new class using the class button in the workbench view. 

• Define this class to implement the interfaces provided by the view. This will generate the skeleton 
code for all the interface methods. 

• Define an instance variable of type same as the view intialised to null. 

• Define a getter method which would create an instance of the view if not created already and 
shows the view. Example: 

private PackageDetails ivjPackageDetailsl = null; 
private PackageDetails getPackageDetailsl 0 { 
if (ivjPackageDetails 1 ~ null) { 
try { 

ivjPackageDetailsl = new com.ibm.icms.usability.msppp.PackageDetailsO; // 
create an instance of the view and show it. 

ivjPackageDetails 1 .setVisible(true); 
// user code end 

} catch (java.lang.Throwable ivjExc) // user code begin {2} 

// user code end 
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handleException(ivjExc); 

) 

return ivjPackageDetails 1 ; 

} 

• Define an intialise method which would add the handler as a subscriber to the interfaces exported 
by the view. Example: 
Void intialize() { 

GetPackageDetailslQ.addPackageDetailsListener(this); 
GetPackageDetailsl().addScrollListener(this); 

} 

• Write the bodies for the methods in the listener interface. This method, eg., PackageOKed, is supposed 
to call server APTs and populate the views using the accessor methods provided by the view. 
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E Steps involved in Client Development 



Item 
No 


Description 


Method 1 

V (view - API) 


Method2 
MV 


Method3 
MVC 


1 


Creation of panels done 
using VisualBuilder. 


X 


X 


X. No extra lines 
of code. 


2 


Create interfaces 






X 

For each 

externally handled 
event fdealinu 
with an API) 1 

line npr event 

■ 111V U W * V» ~ ■ 

Events could be 
loeicallv crouDed 
into interfaces. 


3 


Create getters/setters for the 
view data model to be 

avallaUlv iul Li l w iicLliuid 






X 

For each 

OPttPT/cAttP!" 

mav nppd 1 -S 
lines 


4 


Handlers externally defined 






X. No extra lines 
of code. 


5 


Create Business Objects 




x 


X. No extra lines 
of code. 


6 


Calling the API 


X 


X 


X. No extra lines 
Of code 


7 


Number of objects created 




X. model objects 
created 


X. One extra 
handler object 
per view. Model 
objects created. 




Productivity 










Maintainability 










Quality 










VisuaiAge for Java way of 
doing it 










Alignment with AVI stuff 
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